Ship the OpenVINO delegate as its own library - #21770
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21770
Note: Links to docs will display an error until the docs builds have been completed. ❌ 1 New Failure, 2 Cancelled Jobs, 1 Unrelated Failure, 2 Unclassified FailuresAs of commit 9887bb3 with merge base 09bcc32 ( NEW FAILURE - The following job has failed:
UNCLASSIFIED FAILURES - DrCI could not classify the following jobs because the workflow did not run on the merge base. The failures may be pre-existing on trunk or introduced by this PR:
CANCELLED JOBS - The following jobs were cancelled. Please retry:
BROKEN TRUNK - The following job failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
meta-cla
Bot
added
the
CLA Signed
9428da3 to
2cdf978
Compare
00563b2 to
d3de6d5
Compare
| target_link_libraries(openvino_backend PRIVATE executorch_core ${CMAKE_DL_LIBS}) | ||
| target_link_libraries(openvino_backend PRIVATE ${CMAKE_DL_LIBS}) | ||
|
|
||
| if(EXECUTORCH_BUILD_SHARED) |
There was a problem hiding this comment.
I thought we were not doing all the backends? what made you include this one?
There was a problem hiding this comment.
You are right that this stack is not doing every backend. OpenVINO came in because it was the last delegate still compiled into the Python extension, so it was the one remaining case of the exact problem the stack fixes: only Python could use it, and a C++ app had no way to link it.
It is also cheap to include, since it needed the same treatment already applied to XNNPACK and CUDA. The backends left out are the ones that need real work, not just splitting.
| # stop supporting. Name the two datacentre architectures the release rows | ||
| # build for, so a source build produces device code that runs on the same | ||
| # GPUs the wheels target. | ||
| set(CMAKE_CUDA_ARCHITECTURES "80;86") |
There was a problem hiding this comment.
move this to one of the previous PRs introduces cuda?
There was a problem hiding this comment.
Fair, that hunk does belong with the CUDA PR rather than the OpenVINO one. I will move it down to 21645 so each PR only touches its own backend.
There was a problem hiding this comment.
Correction to my last reply: there is nothing left to move, so I should not have said I would move it.
I checked the current stack and this hunk no longer exists. The set(CMAKE_CUDA_ARCHITECTURES "80;86") change was replaced since your review: the file now reads TORCH_CUDA_ARCH_LIST instead, because torch's CMake rejects and overrides CMAKE_CUDA_ARCHITECTURES anyway, which is also why the release rows publish the former. This PR no longer touches backends/cuda/CMakeLists.txt at all.
So your point was right and is now moot: the CUDA change is not sitting in the OpenVINO PR. Sorry for the noise, I answered from your quoted text without re-checking the code first.
| if sys.platform == "darwin": | ||
| _BUNDLED_THREADPOOL_SYMBOLS = ("cpuinfo_initialize",) | ||
| else: | ||
| _BUNDLED_THREADPOOL_SYMBOLS = ("pthreadpool_create", "cpuinfo_initialize") |
There was a problem hiding this comment.
Is this also OpenVino related?
There was a problem hiding this comment.
Yes. It adds OpenVINO to the same per-component checks the other delegates already have, so the new library is verified to define its symbols exactly once like the rest.
2 participants
The OpenVINO delegate was compiled into the Python extension, so only Python could
use it. A C++ application had no way to link it from the wheel, which is the same gap
the other delegates had before they were split out.
It now builds as its own library and ships beside the runtime, so an application can
ask for it:
Only the adapter ships here. The OpenVINO runtime itself is loaded at run time and is
not part of the wheel, so the component's documentation says to install it separately,
and the wheel does not grow meaningfully: the adapter is a few kilobytes.
The library resolves the runtime from the shared runtime library rather than from the
static core, so the delegate registers into the one registry the process has instead of
a second private one.
Test Plan: built a wheel with OpenVINO enabled on Linux x86_64 and inspected it.
The library ships at executorch/lib/libexecutorch_backend_openvino.so. Its delegate
symbols moved out of the Python extension, 13 in the library and 0 in the extension,
so the process has one copy and one registration. Its only ExecuTorch dependency is
the shared runtime library, and it records no link dependency on OpenVINO, confirming
the runtime is still loaded at run time. Added an ownership row to the shared library
test so a future change that puts the delegate back into the extension fails there.